Methodology and system for dynamic lightweight personalized analytics

ABSTRACT

An embodiment of the present invention is directed to a feedback-based system and methodology for dynamic lightweight personalized analytics (DLPA). Disclosed embodiments include a process for dynamically leveraging various inputs such as behavioral and other analytics types, and using a small number of dynamically adjusted parameters, a small memory footprint and optimal computation, to deliver behavioral and other suggestions for customer behavior. In addition, certain actions are cancelled, prior to their completion, based on new, dynamically discovered customer behaviors.

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims priority to U.S. Provisional Application62/897,360, filed Sep. 8, 2019, the contents of which are incorporatedherein in their entirety.

This application relates to U.S. application Ser. No. 16/914,629, filedJun. 29, 2020, which claims priority to U.S. Provisional Application62/868,950, filed Jun. 30, 2019, the contents of which are incorporatedherein in their entirety.

FIELD OF THE INVENTION

The disclosed teachings relate generally to leveraging consumer datadynamically to conduct fast, behavioral analytics with a small footprintto gain personalized insights for actions. Further, such actions may beterminated prior to completion based on newly discovered customerbehaviors. Potential participants include those in consumer-focusedindustries and entities, and analytics.

BACKGROUND

Many consumer-based companies leverage customer data and associatedpredictive, prescriptive, and other analytic methodologies to gaininsights. Such information can translate into suggestions to improveefficiencies, understand trends, create new potential markets, ordiscover or prevent fraud, to name a few. There is an abundance ofanalytics efforts conducted to gain such insights. With an increasinglyconsumer-centric society, there is a growing focus on behavioralanalytics to understand customer preferences that can translate intomarket gains. Much of this work leverages a plethora of structured andunstructured data that may be siloed and geographically dispersed forinsights.

There are many consumer-focused industries that require small,lightweight, and fast analytics. For example, the prevailing focus inthe remittance industry is the transfer of funds from sender toreceiver. The transfer amounts are small, and users require minimaltransfer times. Moreover, with thin industry profit margins it isimportant that all efforts to assist in transferring funds areefficient, lightweight, and fast. In this and many other industries,there are no significant efforts to build customer relationships,understand their wants, needs and behaviors, and build customer loyalty.However, a study has shown that businesses that develop strong customerconnections outperform their competitors by 85% in sales growth and morethan 25% in gross margin.

There are some efforts to use analytics in the remittance industry. Forexample, current systems use analytics to understand global remittancemarket trends. Others use analytics to discover glitches or behavioranomalies and detect and prevent fraud. Most focus on overall trends andpatterns, not individual behaviors, to gain insights for unique customerofferings. Currently, there are no efforts to develop lightweightpersonalized analytics methodologies to gain insights for customizedservices real time.

These and other drawbacks exist.

SUMMARY OF THE INVENTION

Accordingly, one aspect of the invention is to address one or more ofthe drawbacks set forth above. An embodiment of the present invention isdirected to a system for providing dynamic lightweight personalizedanalytics (DLPA). The system comprises: an interface that receives oneor more inputs via an enterprise payments services bus; a data storethat stores and manages DLPA metrics; and a dynamic lightweightpersonalized analytics engine comprising a computer processor andcoupled to the interface, the computer processor configured to performthe steps of: receiving one or more customer parameters and remittancetrends; accessing, via a customer account database, one or more keyperformance indicators (KPIs); accessing one or more DLPA metrics;wherein the DLPA metrics are impacted by one or more responses to acustomer remittance suggestion; adjusting each of the one or more DLPAmetrics for a predetermined time window for an individual customer; thestep of adjusting comprising: setting DLPA default values for timewindow (TW); for the time window, calculate a new KPI in a KPI array;applying a favorability metric that determines whether to keep a currentmetric or remove the current metric; dynamically processing a pluralityof transaction data based on the one or more adjusted DLPA metrics toachieve memory conservation and optimal computation; based on theprocessing step, generating a set of remittance suggestions andfinancial suggestions; and communicating the set of remittancesuggestions and financial suggestions.

Another embodiment of the present invention is directed to method forproviding dynamic lightweight personalized analytics (DLPA). The methodcomprises the steps of: receiving, via an interface, one or morecustomer parameters and remittance trends; accessing, via a customeraccount database, one or more key performance indicators (KPIs);accessing one or more DLPA metrics; wherein the DLPA metrics areimpacted by one or more responses to a customer remittance suggestion;adjusting, via a dynamic lightweight personalized analytics enginecomprising a computer processor, each of the one or more DLPA metricsfor a predetermined time window for an individual customer; the step ofadjusting comprising: setting DLPA default values for time window (TW);for the time window, calculate a new KPI in a KPI array; applying afavorability metric that determines whether to keep a current metric orremove the current metric; dynamically processing a plurality oftransaction data based on the one or more adjusted DLPA metrics toachieve memory conservation and optimal computation; based on theprocessing step, generating a set of remittance suggestions andfinancial suggestions; and communicating the set of remittancesuggestions and financial suggestions.

According to another embodiment of the present invention, acomputer-readable medium comprising instructions which, when executed bya computer, cause the computer to carry out steps of: receiving, via aninterface, one or more customer parameters and remittance trends;accessing, via a customer account database, one or more key performanceindicators (KPIs); accessing one or more DLPA metrics; wherein the DLPAmetrics are impacted by one or more responses to a customer remittancesuggestion; adjusting, via a dynamic lightweight personalized analyticsengine comprising a computer processor, each of the one or more DLPAmetrics for a predetermined time window for an individual customer; thestep of adjusting comprising: setting DLPA default values for timewindow (TW); for the time window, calculate a new KPI in a KPI array;applying a favorability metric that determines whether to keep a currentmetric or remove the current metric; dynamically processing a pluralityof transaction data based on the one or more adjusted DLPA metrics toachieve memory conservation and optimal computation; based on theprocessing step, generating a set of remittance suggestions andfinancial suggestions; and communicating the set of remittancesuggestions and financial suggestions.

The computer implemented system, method and medium described hereinprovide unique advantages to entities, organizations, merchants, andother users (e.g., consumers, etc.), according to various embodiments ofthe invention. An embodiment of the present invention is directed toproviding dynamic lightweight personalized analytics (DLPA). The variousembodiments include a feedback-based system and methodology for dynamiclightweight personalized analytics (DLPA). Disclosed embodiments includea process for dynamically leveraging various inputs such as behavioraland other analytics types, and using a small number of dynamicallyadjusted parameters, a small memory footprint and optimal computation,to deliver behavioral and other suggestions for customer behavior. Inaddition, certain actions are cancelled, prior to their completion,based on new, dynamically discovered customer behaviors. These and otheradvantages will be described more fully in the following detaileddescription.

BRIEF DESCRIPTION OF THE DRAWINGS

To facilitate a fuller understanding of the present inventions,reference is now made to the appended drawings. These drawings shouldnot be construed as limiting the present inventions but are intended tobe exemplary only.

FIG. 1 is a block diagram of a remittance payments service-orientedarchitecture, in accordance with exemplary embodiments of thedisclosure.

FIG. 2 is a block diagram of a remittance data storage, in accordancewith exemplary embodiments of the disclosure.

FIG. 3 is a block diagram of the types of data stored in a remittancedata storage, in accordance with exemplary embodiments of thedisclosure.

FIG. 4 is a block diagram of the partial contents of a remittance datastore, in accordance with exemplary embodiments of the disclosure.

FIG. 5 is a block diagram of the dynamic lightweight personalizedanalytics (DLPA) engine, in accordance with exemplary embodiments of thedisclosure.

FIG. 6 is a block diagram of the feedback flow of input from thecustomer to the dynamic lightweight personalized analytics (DLPA)engine, in accordance with exemplary embodiments of the disclosure.

FIG. 7 is a flowchart illustrating an exemplary method for selecting thecustomer metrics to be used by DLPA, in accordance with exemplaryembodiments of the disclosure.

DESCRIPTION OF EMBODIMENTS OF THE INVENTION

The following description is intended to convey an understanding of thepresent invention by providing specific embodiments and details. It isunderstood, however, that the present invention is not limited to thesespecific embodiments and details, which are exemplary only. It isfurther understood that one possessing ordinary skill in the art, inlight of known systems and methods, would appreciate the use of theinvention for its intended purposes and benefits in any number ofalternative embodiments, depending upon specific design and other needs.

An embodiment of the present invention is directed to a system andmethodology for dynamic lightweight personalized analytics (DLPA), a newinnovative technology designed to provide individual analytics to gaininsights for developing personalized offerings to build relationshipswith the customer. DLPA leverages a limited number of customer-specific,industry-focused input parameters, other inputs, and a small footprint.

FIG. 1 is a schematic block diagram illustrating one embodiment of theservice-oriented architecture (SOA) 100 of a remittance system designedto process transactions, in accordance with one embodiment of thepresent invention. The system 100, in one embodiment, includes a userinterface 102 that enables a user to send or receive requests, etc. Thisuser interface 102 interacts with the enterprise payments services bus104 to request or receive services. The enterprise payments services bus104 may be configured to transmit data between engines, databases,memories, and other components of the system 100 for use in performingthe functions discussed herein.

The enterprise payments services bus 104 may include one or morecommunication types and utilize various communication methods forcommunications within a computing device. For example, the enterprisepayments services bus 104 may include a bus, contact pin connectors,wires, etc. In some embodiments, the enterprise payments services bus104 may also be configured to communicate between internal components ofsystem 100 and external components accessible through gateway services118, such as externally connected databases, display devices, inputdevices, etc.

There are several services that may compose this SOA 100, includingpayments processing 106, remittance data storage 108, security services110, the remittance analytics engine 112, risk and compliance 114,transaction monitoring 116, and gateway services 118, which aredescribed below. Each of these service components may be software, acomputer-readable program, executing on one of more processors and mayinclude a mainframe computer, a workstation, a desktop computer, acomputer in a smart phone, a computer system in a rack, a computersystem in a cloud, a physical system, a virtual system, and the like.

The system 100, in one embodiment, is the SOA of a remittance system andis a network of software service components in which the illustrativeembodiments may be implemented. The system 100 includes a user interface102 used by a consumer. The consumer represents a person, a softwareprogram, a virtual program, or any other entity that has possession of,can emulate, or other otherwise issue commands to execute transactionsin the system 100. The system 100 includes an enterprise paymentservices bus 104 which accepts and processes commands from the userinterface 102 and other system components. It also enables communicationamong the various services components in the system 100.

As a part of executing a remittance request, the transaction mayleverage payments processing 106 to process the request. The transactionmay also access remittance data storage 108 which is a resource for dataaccess. Security services 110 are also leveraged to ensure the fullsecurity and integrity of funds and data, and to detect and preventfraud. In addition, the remittance analytics engine 112 may be leveragedand serve as the foundation for DLPA. This engine takes as input aplethora of information from the remittance data storage 108 and othercomponents that may enable the remittance analytics engine 112 tooptimize its outputs. The risk and compliance 114 service may providecustomer identification, verification, and other similar services tocomply with relevant governmental regulations and to minimize risk. Thetransaction monitoring 116 service tracks funds transfer behavior andother activities to detect anomalies that may point to fraud. It mayfurther work in concert with security services 110.

Gateway services 118 enable the transfer of funds, data, requests, etc.to externally connected entities for further processing. Such entitiesmay include a computer network, a financial institution, and others thatmay participate in end-to-end remittance or other funds transfer or dataservices. Other similar embodiments will be apparent to persons havingskill in the relevant art.

FIG. 2 is a schematic block diagram illustrating one embodiment of theremittance data storage service 108 used in the processing ofinformation requests. The remittance data storage 108 may be arelational database, or a collection of relational databases, thatutilizes structured query language for the storage, identification,modifying, updating, accessing, etc. of structured data sets storedtherein. This data storage 108 may include a customer account database202 that contains customer account and other related customerinformation. The customer account database 202 may be configured tostore a plurality of consumer account profiles 204 as well as aplurality of customer parameter data 206 and 208 using a suitable datastorage format and schema.

Each customer account profile 204 may be a structured data setconfigured to store data related to a remittance account. Each customeraccount profile 204 may include at least the customer's full name,address, telephone number, birthdate, birth country, a remittanceaccount number, a bank account number, credit card account information,email address, a list of recipients and associated international mobiletelephone numbers, remittance transaction history, a postal mailingaddress, an email address, and other relevant information. The customeraccount profile 204 may also include additional information suitable forcustomer service programs, customer and vendor optimizations, andregulations, such as product data, offer data, loyalty data, rewarddata, usage data, currency-exchange data, mobile money data, fraudscoring, validity of funds, and transaction/account controls. Thecustomer account profile 204 may also include additional informationthat may be used for know-your-customer (KYC) and anti-money laundering(AML) regulations. It may further contain information suitable forperforming the functions discussed herein, such as communication detailsfor transmitting via the enterprise payment services bus 104.

The customer parameter data 206 and 208 may include a wealth of varioustypes or facts or other data (see FIG. 3) about the customer. It is acomponent of other parameters 220 that may be used as input or outputinformation for the remittance analytics engine 112. The customeraccount database 202 may also include DLPA metrics 210 designed toquantify success. Example DLPA metrics may include the recommendationacceptance rate, recommendation impact, acceptance impact, financialaccount acceptance rate, and financial recommendation impact. Inaddition, those skilled in the art will understand this is arepresentative embodiment. There are other similar metrics that may beused in other embodiments. DLPA metrics may be used to trigger when todynamically update parameters or resources used.

The customer parameter data 206 and 208 may also include the customertemperament information, which may be predicted via social media data308 or the number of times the customer contacts support, for example.Furthermore, the customer account database 202 may include keyperformance indicators (KPIs) 212. For example, representative KPIs mayinclude the total funds transferred per customer, the total number oftransfers per customer, the total number of recipients per customer andthe total balances in all financial accounts per customer. KPIs mayrepresent metrics used to evaluate the performance of an application orbusiness.

Also contained in the remittance data storage 108 is the trends database214. It contains a plurality of trend data 216 and 218 that compose theother parameters 220 that may be used as input information for theremittance analytics engine 112. Examples of trend data include averageremittance amounts over all customers, remittance frequencies and timeframes, remittance geographies, remittance increases over holidays orspecial occasions, and other similar metrics. Other similar embodimentswill be apparent to persons having skill in the relevant art.

Presented in FIG. 3. is a schematic block diagram illustrating oneembodiment of specifics regarding the plurality of data that may bestored in the remittance data storage 108. This data may be stored asstructured data sets that may include transaction data 304, externalevents data 306, social media data 308, geolocation data 310, KPIs 212,DLPA metrics 210, customer preferences 314, milestone events 316,recipient data 318 and communications data 320.

Example transaction data 304 may include the transfer amount, transfertime, recipient name and international mobile number, the time periodsince the last transfer initiated by the sender to any receiver, timeperiod since the last transfer initiated by the sender to a specificreceiver, and the final status of a transaction (e.g., completed,cancelled, etc.). Additional data may include metrics to quantifycustomer sentiments such as the number of times or frequency that thecustomer contacted support, time with support, and support outcomes.

Example external events 306 include general remittance transaction data(transfer amounts, frequency, etc.) for other customers using thespecific remittance service or for remittance customers using anyremittance service, public holidays for the sender and receivercountries, natural disasters, immigration policies, the price of oil,global and local recessions.

Example social media data 308 may include messages (e.g., SMS messages)exchanged between sender and receiver, between sender and the remittanceservice provider and between receiver and remittance service provider,and social media posts (e.g., Facebook, Twitter, Instagram, LinkedIn,etc.).

Example geolocation data 310 may include the physical location of senderand receiver when the funds transfer is initiated or received or thephysical location of the sender or receiver at specific or random times.Other similar embodiments will be apparent to persons having skill inthe relevant art.

Example customer preferences 314 are from the perspective of the sender.They may include hobbies, favorite things to do and financialpreferences. Furthermore, DLPA enables the creation of a financial orother account by the customer to save for the future. This account maybe created and funded statically or dynamically. A customer preference314 may include the customer's desire to create a separate account (orsome other activity) based on DLPA analytics, to choose the type ofaccount to create and to determine how to fund the account. For example,a customer preference 314 may be to create a financial or other accountwhen registering for the remittance service, or upon DLPArecommendations when using the remittance service. There are many typesof accounts to be created. The customer may choose between creating abank account for education, starting a business, donating to a charityor some other option for the sender and/or the receiver. The choices maybe general (e.g., the same type of account for sender and eachrecipient), for each recipient, or variable (e.g., a different type ofaccount depending on the recipient or a group of recipients). Othersimilar embodiments will be apparent to persons having skill in therelevant art.

Example milestone events 316 may include birthdays, including milestonebirthdays (e.g., 18, 25, 30, etc.), weddings, anniversaries,graduations, and other special days for the sender or receiver.

Example recipient data 318 may include full name, internationaltelephone number and recipient preferences that are like customerpreferences 314.

Communications data 320 may include the recent types of communicationsbetween sender, receiver, the remittance service provider, and externalentities. Other similar embodiments will be apparent to persons havingskill in the relevant art.

FIG. 4 is a schematic block diagram illustrating one embodiment of theremittance data storage 108 that contains the KPIs 212 and DLPA Metrics210. As shown in FIG. 4, there is a plurality of KPIs 212: 402, 404,406, and 408, contained in the remittance data storage 108, asillustrated in FIG. 4. Also illustrated in FIG. 4 is a plurality of DLPAMetrics 210: 410, 412, 414, and 416. These metrics are contained in theremittance data storage 108.

FIG. 5 is a schematic block diagram illustrating one embodiment of theremittance analytics engine 112, the foundation for DLPA. It includesthe analytics engine 502, which accepts customer parameters 202 andremittance trends 214 as input. They collectively form the otherparameters 220 set of inputs. Other input metrics include the KPIs 212and DLPA Metrics 210. The DLPA Metrics 210 are impacted by responses tocustomer remittance suggestions 508. Such responses are contained in thecustomer input data 510, a component of the DLPA metrics 210. Outputsfor the analytics engine 502 include customer remittance suggestions508, financial suggestions 506 and other suggestions 504.

The customer remittance suggestions 508, financial suggestions 506 andother suggestions 504 may communicate their suggestions to the customerthrough the user interface 104. The financial suggestions 506 and othersuggestions 504 communicate their suggestions to external entities(e.g., banks, etc.) via gateway services 118.

The analytics engine 502 may represent a primary computational enginefor leveraging predictive, customer behavioral and other analyticstechniques for optimal customer remittance suggestions 508, financialsuggestions 506 and other suggestions 504 for DLPA. It further utilizesa plurality of customer parameters 202, remittance trends 214, KPIs 212and DLPA Metrics 210 as input for its calculations. The number of theseinput factors may be constant or change dynamically and may depend onhow they optimize the plurality of outcomes.

Customer remittance suggestions 508 may include recommendations forsending additional funds to one or a plurality of recipients, increasingthe frequency of sending funds to one or a plurality of recipients, orother similar suggestions. Moreover, the customer may agree to specifictransfer amounts and frequency, based on certain analytics triggers,upon customer registration, by default or dynamically. Financialsuggestions 506 may include creating one or a plurality of financeaccounts, based on customer preferences 314. The type and number ofaccounts may be determined upon customer registration for the remittanceservice, by default, or dynamically. The number, type, or frequency ofother suggestions 504 may be determined in a similar manner.

FIG. 6 is a schematic block diagram illustrating one embodiment of thefeedback flow of information 600 from the user interface 104 to thecustomer (user) 602. Once the customer 602 responds to customerremittance suggestions 508, financial suggestions 506 or othersuggestions 504, the customer input 510, which is a component of theDLPA Metrics 210, may be considered by the DLPA engine 514.

FIG. 7 is flow chart illustrating one embodiment of the DLPA methodologyfor choosing or adjusting the key DLPA-Metrics 210 to be used for agiven customer 700. From the start 702, certain parameters will havenon-zero default values that need to be set, as shown by 704. They mayinclude: the time window (TW), the (KPI-Max), the fraction ofrecommendations that are local versus global (LG-Mix), the minimum valuefor total funds transferred (TFT-Min), the minimum value for totalbalances in financial accounts (TB-Max, assuming the existing offinancial accounts), the maximum number of entries in therecommendations array (Rec-Array-Max), the maximum DLPA metrics to beconsidered per customer (DLPA-Max), the memory footprint of eachDLPA-Metric, the trigger used to determine whether to keep, add orremove a DLPA entry from DLPA-Array (DLPA-Trigger), and a flag todetermine whether to remove or replace a DLPA entry (REMOVE). The DLPAalgorithm initially sets these parameters to their defaults.Furthermore, a favorability metric may be associated with eachDLPA-Array entry. This metric may be a counter to determine the numberof times the specific metric in the DLPA-Array increases a specific KPI212. The favorability values (e.g., counter) may also have defaultvalues.

The flow chart 700 is a depiction of a long-term dynamic executionstrategy. Therefore, each DLPA metric 210 is individually changed andevaluated in each time window, beginning with the initial time window706. As a result, it may take several TWs before the full impact of allDLPA metrics 210 is determined. TW may represent time window, a giventime frame for calculating parameters.

Next, for a given time window, TW(i), an embodiment of the presentinvention may calculate the KPIs 212 in the KPI-Array 708 for the givencustomer. Once this is done the next step is to calculate the new valueof the next element 710 in the DLPA-Array, the current metric (CM). Thismay include updates to the memory footprint and computational times foreach metric. If a KPI 212 value increased over this time window, TW(i),record this in the DLPA-Array for CM (e.g., increase the favorabilitycount for CM).

Using the favorability metrics 712 in the DLPA-Array, determine whetherto keep the CM, remove it, or replace it. For example, if thefavorability count for CM is greater than or equal toDLPA-Count-Trigger, then keep the DLPM metric 714. If it is less thanDLPA-Count Trigger, then remove or replace. There can even be a REMOVEflag. If REMOVE 716 is true, then remove the metric 718. If not, thenthe DLPA metric 210 is replaced by another metric 720. The replacementalgorithm may be round robin, most recently used (MRU), or some otherwell-known replacement strategy. One may also have two or more triggersfor keeping, removing, or replacing the DLPA metric 210. The REMOVE flag716 may or may not be used in such situations.

Another embodiment may consider the memory footprint and/or thecomputational times for each DLPA metric 210. Consider the scenariowhere several DLPA metrics 210 have the same or similar impact on KPIs212; however, there is a limited number of DLPA metrics to be consideredper customer. In such situations, the DLPA metrics with the smallestmemory footprints, and/or execution times, will remain in the DLPA-Arraywhile the others are removed.

The next step is to go to the next time window 722, then start theprocess again, by computing the KPIs 708 in this new time window, etc.

The same (or similar) evaluation methodology may be utilized todetermine the list of other parameters (OPs) 220 to be considered forthe specific customer. In these instances, each OP 220 in the OP-Arraymay be individually evaluated for a given TW(i) to determine its impacton the KPIs 212 per customer. In addition, the new memory footprint andcomputation time may be calculated for the OP 220. For example, they maybe added, removed, or replaced using the same (or similar) typealgorithm. In addition to (or instead of) this, the OPs 220 may also beimpacted by the analytics engine 512 component of the remittance engine502.

These are examples using one TW to determine the impact of a singleDLPA-Metric 210 or OP 220 on the KPIs 212 for an individual customer.This can be enhanced to leverage two or more TWs. In such situations,the targeted metrics may be calculated for each TW(i), over the courseof the larger time frame, or just for the larger time frame. In suchsituations, the impact of the KPIs 212 may be evaluated based on thetrend over the course of the multiple time windows. Those skilled in theart are knowledgeable of such embodiments.

As with internal and external events, there are many ways to suggest thecreation or funding of financial accounts using analytics, whether it bebehavioral or other types analytical algorithms. These variousembodiments may be leveraged as part of this process. Furthermore, therecommendations shown are examples in this embodiment and may beenhanced. Various other parameters and suggestions may be leveraged in asimilar method in other embodiments, which will be apparent to personshaving skill in the relevant art.

DLPA Metrics may represent parameters used in DLPA methodology.Exemplary metrics may include the following:

-   -   RAR: recommendation acceptance rate; the fraction of all        recommendations per customer accepted.    -   RI: recommendation impact; the fraction of all recommendations        resulting in an increase in at least one KPI (new KPI value        greater than or equal to current KPI value) in KPI-Array.    -   AI: acceptance impact; the fraction of all customer accepted        recommendations resulting in an increase in at least one KPI in        KPI-Array.    -   AAR: financial account acceptance rate; the fraction of all        financial account recommendations per customer accepted.    -   FM: financial recommendation impact; fraction of all financial        account recommendations resulting in an increase in at least one        KPI in KPI-Array.    -   ORI: other recommendations impact; fraction of all        non-financial-account recommendations resulting in an increase        in at least one KPI in KPI-Array.    -   Rec-Array: an array of past recommendations to the customer,        including the type of recommendation (e.g., financial or other),        and whether accepted.    -   Rec-Array-Max: the maximum number of entries in the Rec-Array.    -   SI: support impact; fraction of favourable support outcomes        resulting in an increase in at least one KPI in customer's        KPI-Array.    -   CI: communications impact; fraction of favourable communications        outcomes resulting in an increase in at least one KPI in        customer's KPI-Array.    -   DLPA-Array: a collection the DLPA metrics of focus per customer,        and whether it favourably impacted each KPI per customer. This        array may also include the memory footprint of each parameter        and the time needed to compute its value and associated values        (e.g., the time needed to compute the impact of each entry on        entries in the KPI-Array).    -   DLPA-Count-Trigger: used to determine when to remove or replace        a DLPA metric.    -   DLPA-Max: the maximum number of DLPA metrics considered per        customer.    -   REMOVE: a flag to determine whether to remove or replace a DLPA        metric in DLPA-Array.

Key Performance Indicators (KPIs) may include the following:

-   -   TFT: Total funds transferred per customer (sender)    -   TFT-Min: the minimum value for TFT    -   TNT: Total number of transfers per customer    -   TB: Total balances in all financial accounts per customer    -   TB-Min: the minimum value for TB    -   NR: Total number of recipients per customer    -   NFA: Total number of financial accounts per customer    -   KPI-Array: a collection of the KPIs of focus per customer    -   KPI-Max: the maximum number of KPIs considered per customer

LG-Mix may represent a fraction of all DLPA suggestions (local andglobal) that are local.

Other Parameters may include DLPA parameter and trend data as describedin U.S. Provisional Application No. 62/868,950 and U.S. patentapplication Ser. No. 16/914,629, the contents of which are incorporatedherein in their entirety.

Examples may include the LG-Mix, transaction data, external events,social media data, geolocation data, communications data, recipientdata, milestone events, trend data, etc.

-   -   OP-Array: an array of other parameters used for the specific        customer; this array may also include the memory footprint of        each parameter, as well as associated computation times for        calculating its value and impact on KPIs.    -   OP-Max: the maximum number of OPs considered per customer.

TW-Trigger may represent the number of time windows surpassed beforeexecuting decision-making actions (e.g., executing an action if a KPIhas reached its minimum value).

Reference throughout this specification to “one embodiment,” “anembodiment,” or similar language means that a feature, structure, orcharacteristic described about the embodiment is included in at leastone embodiment. Thus, appearances of the phrases “in one embodiment,”“in an embodiment,” and similar language throughout this specificationmay, but do not necessarily, all refer to the same embodiment, but mean“one or more but not all embodiments” unless expressly specifiedotherwise. The terms “including,” “comprising,” “having,” and variationsthereof mean “including but not limited to” unless expressly specifiedotherwise. An enumerated listing of items does not imply that any or allthe items are mutually exclusive and/or mutually inclusive, unlessexpressly specified otherwise. The terms “a,” “an,” and “the” also referto “one or more” unless expressly specified otherwise.

Furthermore, the described features, advantages, and characteristics ofthe embodiments may be combined in any suitable manner. One skilled inthe relevant art will recognize that the embodiments may be practicedwithout one or more of the specific features or advantages of anembodiment. In other instances, additional features and advantages maybe recognized in certain embodiments that may not be present in allembodiments.

The present invention may be a system, a method, and/or a computerprogram product. The computer program product may include a computerreadable storage medium (or media) having computer readable programinstructions thereon for causing a processor to carry out aspects of thepresent invention.

The computer readable storage medium can be a tangible device that canretain and store instructions for use by an instruction executiondevice. The computer readable storage medium may be, for example, but isnot limited to, an electronic storage device, a magnetic storage device,an optical storage device, an electromagnetic storage device, asemiconductor storage device, or any suitable combination of theforegoing. A non-exhaustive list of more specific examples of thecomputer readable storage medium includes the following: a portablecomputer diskette, a hard disk, a random access memory (RAM), aread-only memory (ROM), an erasable programmable read-only memory (EPROMor Flash memory), a static random access memory (SRAM), a portablecompact disc read-only memory (CD-ROM), a digital versatile disk (DVD),a memory stick, a floppy disk, a mechanically encoded device such aspunch-cards or raised structures in a groove having instructionsrecorded thereon, and any suitable combination of the foregoing. Acomputer readable storage medium, as used herein, is not to be construedas being transitory signals per se, such as radio waves or other freelypropagating electromagnetic waves, electromagnetic waves propagatingthrough a waveguide or other transmission media (e.g., light pulsespassing through a fiber-optic cable), or electrical signals transmittedthrough a wire.

Computer readable program instructions described herein can bedownloaded to respective computing/processing devices from a computerreadable storage medium or to an external computer or external storagedevice via a network, for example, the Internet, a local area network, awide area network and/or a wireless network. The network may comprisecopper transmission cables, optical transmission fibers, wirelesstransmission, routers, firewalls, switches, gateway computers and/oredge servers. A network adapter card or network interface in eachcomputing/processing device receives computer readable programinstructions from the network and forwards the computer readable programinstructions for storage in a computer readable storage medium withinthe respective computing/processing device.

Computer readable program instructions for carrying out operations ofthe present invention may be assembler instructions,instruction-set-architecture (ISA) instructions, machine instructions,machine dependent instructions, microcode, firmware instructions,state-setting data, or either source code or object code written in anycombination of one or more programming languages, including an objectoriented programming language such as Java, Smalltalk, C++ or the like,and conventional procedural programming languages, such as the “C”programming language or similar programming languages. The computerreadable program instructions may execute entirely on the user'scomputer, partly on the user's computer, as a stand-alone softwarepackage, partly on the user's computer and partly on a remote computeror entirely on the remote computer or server. In the latter scenario,the remote computer may be connected to the user's computer through anytype of network, including a local area network (LAN) or a wide areanetwork (WAN), or the connection may be made to an external computer(for example, through the Internet using an Internet Service Provider).In some embodiments, electronic circuitry including, for example,programmable logic circuitry, field-programmable gate arrays (FPGA), orprogrammable logic arrays (PLA) may execute the computer readableprogram instructions by utilizing state information of the computerreadable program instructions to personalize the electronic circuitry,to perform aspects of the present invention.

Aspects of the present invention are described herein with reference toflowchart illustrations and/or block diagrams of methods, apparatus(systems), and computer program products according to embodiments of theinvention. It will be understood that each block of the flowchartillustrations and/or block diagrams, and combinations of blocks in theflowchart illustrations and/or block diagrams, can be implemented bycomputer readable program instructions.

These computer readable program instructions may be provided to aprocessor of a general-purpose computer, special purpose computer, orother programmable data processing apparatus to produce a machine, suchthat the instructions, which execute via the processor of the computeror other programmable data processing apparatus, create means forimplementing the functions/acts specified in the flowchart and/or blockdiagram block or blocks. These computer readable program instructionsmay also be stored in a computer readable storage medium that can directa computer, a programmable data processing apparatus, and/or otherdevices to function in a manner, such that the computer readable storagemedium having instructions stored therein comprises an article ofmanufacture including instructions which implement aspects of thefunction/act specified in the flowchart and/or block diagram block orblocks.

The computer readable program instructions may also be loaded onto acomputer, other programmable data processing apparatus, or other deviceto cause a series of operational steps to be performed on the computer,other programmable apparatus or other device to produce a computerimplemented process, such that the instructions which execute on thecomputer, other programmable apparatus, or other device implement thefunctions/acts specified in the flowchart and/or block diagram block orblocks.

The flowchart and block diagrams in the Figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods, and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof instructions, which comprises one or more executable instructions forimplementing the specified logical function(s). In some alternativeimplementations, the functions noted in the block may occur out of theorder noted in the figures. For example, two blocks shown in successionmay, in fact, be executed substantially concurrently, or the blocks maysometimes be executed in the reverse order, depending upon thefunctionality involved. It will also be noted that each block of theblock diagrams and/or flowchart illustration, and combinations of blocksin the block diagrams and/or flowchart illustration, can be implementedby special purpose hardware-based systems that perform the specifiedfunctions or acts or carry out combinations of special purpose hardwareand computer instructions.

Many of the functional units described in this specification have beenlabelled as modules, to emphasize their implementation independence moreparticularly. For example, a module may be implemented as a hardwarecircuit comprising custom VLSI circuits or gate arrays, off-the-shelfsemiconductors such as logic chips, transistors, or other discretecomponents. A module may also be implemented in programmable hardwaredevices such as field programmable gate arrays, programmable arraylogic, programmable logic devices or the like.

Modules may also be implemented in software for execution by varioustypes of processors. An identified module of program instructions may,for instance, comprise one or more physical or logical blocks ofcomputer instructions which may, for instance, be organized as anobject, procedure, or function. Nevertheless, the executables of anidentified module need not be physically located together but maycomprise disparate instructions stored in different locations which,when joined logically together, comprise the module and achieve thestated purpose for the module.

Furthermore, the described features, structures, or characteristics ofthe embodiments may be combined in any suitable manner. In the followingdescription, numerous specific details are provided, such as examples ofprogramming, software modules, user selections, network transactions,database queries, database structures, hardware modules, hardwarecircuits, hardware chips, etc., to provide a thorough understanding ofembodiments. One skilled in the relevant art will recognize, however,that embodiments may be practiced without one or more of the specificdetails, or with other methods, components, materials, and so forth. Inother instances, well-known structures, materials, or operations are notshown or described in detail to avoid obscuring aspects of anembodiment.

1. A system for providing dynamic lightweight personalized analytics (DLPA), the system comprising: an interface that receives one or more inputs via an enterprise payments services bus; a data store that stores and manages DLPA metrics; and a dynamic lightweight personalized analytics engine comprising a computer processor and coupled to the interface, the computer processor configured to perform the steps of: receiving one or more customer parameters and remittance trends; accessing, via a customer account database, one or more key performance indicators (KPIs); accessing one or more DLPA metrics; wherein the DLPA metrics are impacted by one or more responses to a customer remittance suggestion; adjusting each of the one or more DLPA metrics for a predetermined time window for an individual customer; the step of adjusting comprising: setting DLPA default values for time window (TW); for the time window, calculate a new KPI in a KPI array; applying a favorability metric that determines whether to keep a current metric or remove the current metric; dynamically processing a plurality of transaction data based on the one or more adjusted DLPA metrics to achieve memory conservation and optimal computation; based on the processing step, generating a set of remittance suggestions and financial suggestions; and communicating the set of remittance suggestions and financial suggestions.
 2. The system of claim 1, wherein the DLPA metrics comprise one or more of: recommendation acceptance rate; recommendation impact; acceptance impact, financial account acceptance rate; financial recommendation impact, an array of past recommendations to the customer.
 3. The system of claim 1, wherein the DLPA metrics comprise one or more of: support impact, communications impact.
 4. The system of claim 1, wherein KPI represents total funds transferred; total number of transfers, total balances, total number of recipients, and total number of financial accounts.
 5. The system of claim 1, wherein the transaction data comprises one or more of: milestone events, social media data, and geolocation events.
 6. The system of claim 1, wherein the computer processor is further configured to perform the step of: adjusting each of the one or more DLPA metrics for a next time window for the individual customer.
 7. The system of claim 1, wherein the DLPA metrics represent a predetermined number of customer-specific and industry focused input parameters.
 8. The system of claim 1, wherein the dynamic lightweight personalized analytics (LPA) engine is executed to gain insights for customized services in real-time.
 9. A method for providing lightweight personalized analytics (LPA), the method comprising the step of: receiving, via an interface, one or more customer parameters and remittance trends; accessing, via a customer account database, one or more key performance indicators (KPIs); accessing one or more DLPA metrics; wherein the DLPA metrics are impacted by one or more responses to a customer remittance suggestion; adjusting, via a dynamic lightweight personalized analytics engine comprising a computer processor, each of the one or more DLPA metrics for a predetermined time window for an individual customer; the step of adjusting comprising: setting DLPA default values for time window (TW); for the time window, calculate a new KPI in a KPI array; applying a favorability metric that determines whether to keep a current metric or remove the current metric; dynamically processing a plurality of transaction data based on the one or more adjusted DLPA metrics to achieve memory conservation and optimal computation; based on the processing step, generating a set of remittance suggestions and financial suggestions; and communicating the set of remittance suggestions and financial suggestions.
 10. The method of claim 9, wherein the DLPA metrics comprise one or more of: recommendation acceptance rate; recommendation impact; acceptance impact, financial account acceptance rate; financial recommendation impact, an array of past recommendations to the customer.
 11. The method of claim 9, wherein the DLPA metrics comprise one or more of: support impact, communications impact.
 12. The method of claim 9, wherein KPI represents total funds transferred; total number of transfers, total balances, total number of recipients, and total number of financial accounts.
 13. The method of claim 9, wherein the transaction data comprises one or more of: milestone events, social media data, and geolocation events.
 14. The method of claim 9, further comprising the step of: adjusting each of the one or more DLPA metrics for a next time window for the individual customer.
 15. The method of claim 9, wherein the DLPA metrics represent a predetermined number of customer-specific and industry focused input parameters.
 16. The method of claim 9, wherein the dynamic lightweight personalized analytics (LPA) engine is executed to gain insights for customized services in real-time.
 17. A computer-readable medium comprising instructions which, when executed by a computer, cause the computer to carry out steps of: receiving, via an interface, one or more customer parameters and remittance trends; accessing, via a customer account database, one or more key performance indicators (KPIs); accessing one or more DLPA metrics; wherein the DLPA metrics are impacted by one or more responses to a customer remittance suggestion; adjusting, via a dynamic lightweight personalized analytics engine comprising a computer processor, each of the one or more DLPA metrics for a predetermined time window for an individual customer; the step of adjusting comprising: setting DLPA default values for time window (TW); for the time window, calculate a new KPI in a KPI array; applying a favorability metric that determines whether to keep a current metric or remove the current metric; dynamically processing a plurality of transaction data based on the one or more adjusted DLPA metrics to achieve memory conservation and optimal computation; based on the processing step, generating a set of remittance suggestions and financial suggestions; and communicating the set of remittance suggestions and financial suggestions.
 18. The computer-readable medium of claim 17, wherein the DLPA metrics comprise one or more of: recommendation acceptance rate; recommendation impact; acceptance impact, financial account acceptance rate; financial recommendation impact, an array of past recommendations to the customer.
 19. The computer-readable medium of claim 17, wherein KPI represents total funds transferred; total number of transfers, total balances, total number of recipients, and total number of financial accounts.
 20. The computer-readable medium of claim 17, wherein the DLPA metrics represent a predetermined number of customer-specific and industry focused input parameters. 